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ABSTRACT 

Decision Support Systems (DSS) have been identified as a 
solution to the military commander's needs for information 
filtering and analysis. Current literature on the theory and 
techniques of DSS design have been addressed to the decision- 
making processes of commercial applications. The lack of a 
comprehensive treatement of military command and control 
decision-making requirements may result in a number of 
command and control DSS which are not designed for the 
reliability and flexibility required in a context of ever- 
changing threats. This thesis is an initial attempt to 
identify some unique considerations for the design of a 
command and control decision support system and offers 
suggestions towards the development of flexible, reliable 
systems to serve commanders in both peacetime and combat 
operations. 
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I. INTRODUCTION 



The Navy has been using computers longer than any other 
organization. The Harvard Mark I and the ENIAC were 
providing data for ballistic studies in the late 1940's. 
Since then, the Navy has become dependent on computers for 
virtually all its essential activities from payroll to 
weapons control [Ref. 1: pp. 6-7]. While such extensive 
employment of computing capabilities has without doubt 
allowed the Navy to run a leaner, more capable operation, it 
has also resulted in the same "information overload" problem 
which has received so much publicity in the business press. 

Managers and businessmen in the private sector have long 
complained that the so-called Management Information Systems, 
or MIS, have had little or no beneficial effect on managerial 
decision-making. Managers do not need more data; they need a 
way to filter data, to view it from different angles, to make 
projections, and to conduct variance and sensitivity 
analyses. The concept of Decision Support Systems (DSS) , 
which was made possible in the late 1960's with the 
introduction of time sharing and remote terminals, provided 
the potential for managers to use information "instead of 
being buried under it" [Ref. 2: p. 33 ]. 
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Most discussion of the use of DSS to support military 
decision-making is limited to proposals and suggestions. 
While several projects are underway to field prototype DSS, 
the actual capability to perform analyses on data is usually 
planned for later versions of the system. This is especially 
true for systems which will support such complex and 
dif f icult-to-def ine missions such as command and control. 

Still, the need is there; commanders on ships and in the 
field are just as inundated with data as any other manager, 
if not considerably more so. DSS promises to help these 
commanders filter information, analyze data, compare 
alternatives and transmit commands, all from the same 
console. 

The Soviets also see the need for command and control 
DSS. Fleet Admiral Gorshkov shares our Secretary of 
Defense's opinion that the status of a force's Command and 
Control elements will be an equally important determinant in 
war as that of the level of technology of weapons systems 
[Ref. 3: p. 7, Ref. 4: p. 241]. Gorshkov recently presented 
a paper in which he identifies the modeling and analytical 
capabilities of a Command and Control decision-supporting 
computer system as capabilities which will be essential to 
permit commanders to make decisions in an environment which 
will be distinguished by the "large spatial scope, 
accelerated tempo, and sharp variation in the situation...." 
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with a well-established need, and with the increasing 
recognition of the importance of Command and Control, it is 
not at all surprising that the concept of Command and Control 
DSS has already attracted much attention in the Navy. 
Unfortunately, current textbooks and actual DSS examples are 
strictly commercial applications for such purposes as 
financial and production management. Military planners or 
project managers who will be responsible for the design 
specifications of Command and Control DSS will find very 
little in the way of formal guidance. 

The purpose of this research, then, is to consolidate 
what information available in the scattering of applicable 
articles in military journals with this author's knowledge of 
Navy command and control to provide a general outline of 
unique considerations in the design of a Command and Control 
DSS. It is hoped that this thesis will also serve to 
stimulate further interest and research towards more complete 
and formal textbooks or manuals on the subject. 
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II. A PLACE FOR DSS IN COMMAND AND CONTROL 



Command and control has always been an important element 
in war, and in this age of nuclear weapons and the need for 
instant response, it has become even more important. Soviet 
Fleet Admiral Gorshkov emphasizes the role of command and 
control in warfare, "Disrupting enemy control of forces in a 
number of instances can produce no less an effect than their 
immediate defeat..." [Ref. 3: p. 9]. 

The current administration has recognized this critical 
role of command and control. In his Annual Report to the 
Congress for Fiscal Year 1984, Defense Secretary Weinberger 
emphasizes the dependence of force capability upon command 
and control systems [Ref. 4: p. 241]. Roughly $15 billion a 
year is now being invested in these systems, making command 
and control the fastest growing functional component of the 
U.S, defense budget [Ref. 5: p. 28]. 

A. TODAY'S COMMAND AND CONTROL SYSTEMS: THE CHALLENGE 

As Secretary Weinberger states in the FY 1984 Report, 
"The variety and complexity of our C3l* systems presents us 
with an extremely challenging management task" [Ref, 4: p. 
241]. Most of our command and control systems evolved 

*"C3I" is the acronym for Command, Control, Communica- 
tions, and Intelligence. 



11 



1 



independently and are supported by a collection of equipment 
whose architectures are 15 to 30 years old, with low meantime 
between failure and high maintenance costs. Like many other 
military computer systems they involve software which is 
"non-portable, inflexible and largely unresponsive, expensive 
to develop and maintain, with little or no interoperability 
and few standards.." [Ref. 6: p. 26].] 

The challenge today is to upgrade and integrate current 
command and control systems and to develop and acquire new 
systems which [Ref. 4: pp. 241-242]: 

- provide a "proper mix" with weapons systems, 

- can evolve with changing needs for information, 

- are affordable, 

- meet the requirements of the decisionmakers they will 
serve , 

- are survivable in both lethal and electronic warfare, 

- are interoperable, both among our own Services and with 
our allies, in joint and combined military operations, 

- are consistent with long range plans developed jointly 
with the Defense Intelligence Agency and the JCS. 

Obviously, such goals will not be achieved overnight. 

Command and control is a very complex mission. Robert B. 

Doane of the Air Force Systems Command's Electronic Systems 

Division states that before it will be possible to develop a 

satisfactory command and control architecture, it is first 

necessary to undertake "...a concerted effort to define, 

with a degree of stability, the top-level information needs 
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for all levels of command/ ...from the 'local' (battle) 
commanders up through the JCS — a very difficult task" [Ref. 
7 : p. 182]. 



B. DIFFERENT CONCEPTS OF COMMAND AND CONTROL 

Still Others say that command and control defies precise 
definition, [Ref. 8; pp. 96] and that the "absence of a 
succinct statement of objectives" at the national level has 
resulted in command and control systems which have been 
driven instead by the push for technological sophistication. 
[Ref. 9; pp. 48-69]. 

There are indeed many different concepts of command and 

control. The JCS Pub 1 offers this definition; 

"The exercise of authority and direction by properly 
designated commanders over assigned forces in the 
accomplishment of his mission. Command and control 
functions are performed through an arrangement of 
equipment, communication, facilities and procedures in 
planning, directing and controlling forces and operations 
in the accomplishment of his mission" [Ref. 7; p. 182]. 

Another definition of command and control emphasizes the 



process of decision-making [Ref. 10; p. 15] ; 



"..a process; or, more accurately, a set of related 
processes. It is, first, a process of getting information 
to decision makers. Second, it is a process of 
interaction between decision makers. Third, it is a 
process of implementing their decisions. All three of 
these vital processes are centered around decision makers; 
the task of command and control is to help them see more 
clearly what is happening, decide what to do about it and 
implement the necessary actions. " 

It is this latter definition which, in the opinion of 
this writer, will best support efforts to design integrated 
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command and control systems. Its emphasis on the decision 
maker is more promising in achieving Secretary Weinberger's 
goal of developing systems which will serve the information 
needs of the intended users. Its division of the process of 
command and control into the three 'subprocesses' of 
gather ing information, interaction among decision-makers and 
implem en ti ng decisions highlights the importance of 
communications in command and control decision making. It 
also closely resembles Simon's paradigm of decision making* 
and thus allows inspection of current command and control 
systems as to how well they support each of the three stages 
of decision making. 

C. COMMAND AND CONTROL DECISION-MAKING 

The decision-making phases identified by Simon are the 
"intelligence" phase, the "design", phase and the "choice" 
phase. The decision-making process involves the iteration of 
these phases, where "intelligence" is the gathering of data, 
"design" is the manipulation and analysis of the data, and 
"choice" is the selection and implementation of a course of 
action. 

The intelligence phase of decision-making in command and 
control, or the gathering of information is already well- 
supported by sophisticated sensors and communications 



*See Appendix, Section C. 
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technology. It is the design and choice phases, in which 
alternatives are evaluated and implemented, where current 
command and control systems provide little support for 
commanders. The Assistant Secretary of the Navy (Research, 
Engineering and Systems), John Paisley was quoted in SIGNAL 
Magazine [Ref. 11; p. 23]: 

"Our ability to collect, process and transport information 
at prodigious rates is great and continues to expand and 
already has exceeded our ability to assimilate and 
comprehend. The commander... has more information than he 
can use. The difficulty is that the information is not 
always in the right form or presentation and it may not be 
available 'in-time,' but without question, he has more than 
he can use." 

Commanders must be provided some means for "assessment, 
aggregation and correlation of vasts amounts of data" and 
some way of "filtering the essentials to decision makers at 
every level" [Ref. 12: p. 18]. Without such a means to 
manage this "information explosion", decision-makers faced 
with complex decisions and short time frames must rely soley 
on their own heuristic problem-solving abilities which are 
limited by small short term memory capacity and the serial, 
one-pr ocess-a t-a- t ime mode of operation [Ref. 13: p. 40]. 
Because the nature of modern warfare involves tremendously 
fast and accurate weapons, there will be no time to perform 
this relatively slow mental problem-solving process for 
optimal solutions. While "satisficing," or "settling for a 
good-enough" solution may serve the needs of other decision 
makers [Ref. 14; p. 449], it is not a desirable method for 
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problem-solving when the consequences can affect the lives of 
men or the defense and reputation of the country. 

The heuristic process of human decision-making can also 
result in distortions or biases [Ref. 15: p. 119]. The 
decision maker will search for relevant information, but will 
use only that which can be made available in the given time 
frame. He may interpret data differently depending on the 
order or method of presentation. He may select for retention 
only that data or information which he understands, or in 
which he has particular interest or knowledge. His 
expectations may prevent him from accepting the significance 
of contradictory information. The frequency of recent events 
can cause the decision maker to overlook the more crucial 
measure of rate of occurance. Variables may be erroneously 
correlated and inferences can be inappropriately derived from 
insignificantly small samples. These are just a few of the 
problems associated with unaided human decision making. The 
consequences for command and control decisions could be at 
best inefficient, at worst, disastrous. 

D. DSS FOR COMMAND AND CONTROL 

One method to improve the effectiveness of command and 
control decision making while eliminating at least some of 
these human biases, is to provide commanders with decision 
support systems [Ref. 16: p. 45]. A prototype DSS, the 
Tactical Flag Command Center (TFCC) , is currently under 
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development and will provide Navy Officers in Tactical 
Command a "battle station which is automated to assimilate 
and display organic and non organic sensor tactical data" and 
will "enable him to coordinate and control assigned tasks in 
the increasingly complex tactical situations..." [Ref. 17: p. 
32-33]. Other such systems are being planned to support 
commanders in all services. 

Evidently the need to support decision makers in all 
three phases of decision making has been recognized. DSS may 
well be the answer. However, the fielding of such systems 
cannot be done successfully without careful planning and 
integration into an overall systems architecture. Command 
and control systems must be interoperable and survivable if 
they are to serve decision makers in combat environments. 
They must be integrated with complex weapons systems and thus 
incorporate some well-defined strategies and tactics. 
Furthermore, they must be affordable and take into 
consideration life cycle costs of maintenance. 

The design of command and control DSS is much more 
complicated than that of a DSS intended for commercial uses. 
The following chapter will attempt to identify some of the 
major difficulties associated with developing such a system 
for command and control. 
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III. FITTING A DSS INTO THE COMMAND AND CONTROL 
ARCHITECTURE; ORGANIZATIONAL AND TECHNICAL 
CONSIDERATIONS 

A. IMPLEMENTING NEW TECHNOLOGY 

A DSS cannot be bought 'off the shelf and simply 
"plugged in." Instead, the design and implementation must 
involve analyses of (1) the implicit affects upon the users 
and upon the context or organization in which they operate, 
and (2) limitations or requirements imposed by the supporting 
technology. Too often, the implementation of a new 
technology has been viewed as a "discrete-entity" process in 
which the technical merits of the new system(s) would 
determine effectiveness, independently of the specific 
characteristics of the organization [Ref. 18; pp. 7-8]. Such 
a practice is at least partly responsible for the lack of 
integration of the various components of the current command 
and control architecture [Ref. 19; p. 16]. 

A DSS is a form of technology in that it is a technique 
by which an organization or individual transforms inputs to 
outputs and which involves equipment, automation, and 
problem-solving methods. Thus, the implementation of a DSS 
can "require subsequent changes in task, structure or 
individual" [Ref. 20; p. 126]. Some of these changes may be 
easily predicted, some easily quantified in terms of cost. 
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More thoughtful analyses usually result in the identification 
of affects which are not readily quantified in terms of 
expected costs [Ref. 21: p. 223]. 

An attempt to estimate the costs associated with the 
implementation of a DSS for command and control purposes in 
the military will be very difficult, for there has been very 
little effort to develop a theory of current command and 
control decision making processes [Ref. 8: p. 45-49, Ref. 22: 
p. 45-49]. A cost/benefit analysis would be extremely 
difficult, if not impossible, without some understanding and 
ability to quantify, for purposes of comparison, the 
effectiveness of the current methods of command and control 
decision-making . 

It is possible, and highly advisable when introducing a 
new system into an environment cha r ac ter i z ed by high 
technology and low structure (low level of integration), that 
some attempt is made to identify the "area of change" and 
perform what is has come to be known as a "risk analysis" 
[Ref. 23: p. 325]. Such a risk analysis is undertaken for 
early identification of potential problem areas and 
appropriate managerial or technical means by which to lessen 
the risks. 

This chapter presents some organizational and technical 
factors which may require consideration by those who are 
responsible for the development of a command and control DSS. 
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The list is by no means complete, for depending on the 
particular situation and environment there will probably be 
more specific factors which will also require attention. The 
intent here is to develop an appreciation for some of the 
generally-applicable, but often neglected, organizational and 
technical factors which can affect the performance of a DSS 
in a command and control setting. 

B. ORGANIZATIONAL FACTORS 
1 . Strategic Balance 

Dramatic improvements in our command and control 
capabilities could have the effect of negating or reducing 
one or more perceived advantages of an adversary's weapons 
capabilities (Ref. 24: p. 4, Ref. 25; p. 248]. It would then 
be possible that the new command and control capability may 
itself become the subject of strategic arms negotiations 
[Ref. 26; p. 424]. If the DSS should incorporate real-time 
satellite data for an improved ability to "scan the 
battlefield," it may well raise questions as to whether this 
will increase or decrease the likelihood that nuclear weapons 
will be used [Ref. 27: p. 26]. The impact of new command and 
control capabilities on the strategic balance and on arms 
talks will largely depend on whether the new capabilities are 
perceived by our adversaries, especially the Soviet Union, as 
offensive or as defensive capabilities [Ref. 25; p. 246]. 
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2. Centralized vs. Decentralized Command Authority 



Depending on the communications capabilities provided 
in the design, a command and control DSS may further the 
trend towards centralization of command authority. If the 
DSS is designed to meet the objective of enhancing 
communications among the various echelons of command, it may 
provide central headquarters authorities with rapid feedback 
of subordinate actions and with the ability to monitor in a 
real-time manner, the behavior and events at the lower 
echelons [Ref. 20: p. 177]. This will be viewed favorably by 
those who feel that the threat of escalation to nuclear 
exchange mandates central control during any conflict [Ref. 
20: p. 141, Ref. 28: p.8. Ref. 29: p. 266]. Others argue 

that commanders at the level of engagement have neither the 
time nor the inclination to accept control from remote 
authority [Ref. 30: p. 45, Ref. 31: p. 23, Ref. 32: p. 20]. 

Computers themselves do not enforce centralization or 
decentralization of authority. The choice is one of strategy 
and politics. The issue has already attracted much debate 
and has produced concepts of command and control which differ 
as to degree and location of control and responsibility. The 
Composite Warfare Commander and the Fleet Command Center 
concepts are two examples, the former advocating 
decentralization of control of warfare mission areas to at 
least 3 warfare commanders, the latter holding that control 
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by safely remote experts will simplify decision-making for 
on-scene commanders. 



Before it will be possible to establish the 
information requirements of the users of a proposed command 
and control DSS, it will be necessary to agree on this aspect 
of command [Ref. 33: p. 31, Ref. 34: p. 418]. 

3 . Defense Strategy 

If the DSS is to provide the commander with such 
capabilities as threat evaluation, targeting prioritization, 
and situation analysis, it will necessarily involve models 
which cannot be designed without a clear definition of 
defense strategy and associated tactics. Critics argue that 
no such clearly defined strategy exists [Ref. 35, Ref. 36: 
pp. 9-12, Ref. 37, Ref. 38: p. 14). Others suggest that 
current strategy has fallen out of step with the new threats 
and new weapons capabilities, especially in that forces and 
tactics are organized for a war of attrition when modern 
warfare's dispersed and decentralized characteristics more 
appropriately call for maneuverability and deception [Ref. 
39: p. 18, Ref. 40: p. 33, Ref. 41]. 

The role of command and control capabilities and 
facilities in supporting the defense strategy must also be 
defined in order to design and implement an effective command 
and control DSS. Today there are no clear statements of 
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objectives for command and control support of the forces 
[Ref. 9: p. 52]. 

4. Interoperability 

In the past, disregard for the interdependencies of 
various command and control systems has resulted in "separate 
programs, different rates of evolution, different 
protocols.." [Ref. 19: p. 18]. Don Latham, DUSD for C3I, 
referred recently to the almost unbelievable interoperability 
problems which have resulted. The present command and 
control resources "must be integrated into an overall plan to 
insure efficient employment and to avoid duplication of 
capabilities in future procurement" [Ref. 42: p. 2]. 

Interoperability of command and control systems is 
not an issue which can be addressed as an afterthought. 
Modern warfare with its broad area sensors and long range 
weapons requires that information be rapidly and reliably 
exchanged among systems at a variety of levels of command, 
between forces of the various services and between the United 
States and its allies [Ref. 43: p. 45]. It may even be 
advisable, considering the confusion and uncertainty 
surrounding the scene of future warfare [Ref. 44] and the 
constant threat of escalation, that our command and control 
systems be designed for "adversarial communications," or 
interoperability with non-friendly forces [Ref. 45: p. 90]. 
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While it may be neither feasible nor desirable to 
design a given DSS for interoperability with all of the major 
systems, identification of desirable connectivity in the 

early stages of the system development cycle will reduce 
costly efforts to upgrade the system for such a capability at 
a later date. 

5 . Command Responsibility 

The research involved in the preparation of this 
thesis uncovered not a single mention of the issue of 
responsibility for results of command decisions which are 
based on the information provided by a command and control 
DSS. Nevertheless, the issue seems worth mentioning; perhaps 
it will be raised officially once DSS actually become 
operational in command and control settings. 

If the commander today is to be provided with a set 
of models and data to help him deal with the so-called data- 
explosion, then will he still be held responsible for the 
accuracy of those models and data? If the DSS is to be used 
under combat or crisis situations, will the commander be 
expected to assess the validity of the results of his queries 
to the system. It is not inconceivable that an error in the 
design of a model, or in the transparent data source could go 
undetected until the investigation which would follow an 
unfortunate, and possibly, a very costly, decision. 
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Clarification of this issue before asking commanders 
to use a DSS may at least serve to develop in those 
commanders a desire to fully understand the models and 
capabilities provided by the system. To neglect this issue 
is to risk reinforcement of a common tendency to distrust 
both models and computers — a result which will negate the 
potentials of DSS in command and control. 

C. TECHNICAL CONSIDERATIONS 

Command and control systems must be both reliable and 
flexible. The degrees of reliability and flexibility needed, 
and the ability to achieve them, is largely a function of the 
particular uses and operating environments of each system. 
The operating environment of a tactical command and control 
system presents more design problems than that of a 
strategic system due to the more restrictive availability of 
maintenance support, power, and space aboard mobile 
platforms. The following technical considerations for the 
design of a command and control DSS are discussed in terms of 
flexibility and reliability and apply specifically to 
tactical systems. Some of these comments may prove equally 
applicable to strategic systems. 

1. Flexibility 

The rapidly changing nature of the command and 
control environment and of computer hardware and software 
technology calls for a great deal of flexibility in the 
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components of the DSS. The modular concepts of software 
engineering as described by Constantine, Myers and Stevens 
[Ref. 46; pp. 115-138] will be useful for a command and 
control DSS. The basic idea is to design the system as a set 
of loosely-coupled segments where any one function is fully 
contained within a single segment, or module. This allows 
the isolation into separate modules of the various likely 



"areas of change." The same modular concept can be applied to 
the design of the hardware components at the box, board or 
chip level [Ref. 39: p. 2]. While the details of the 



processing techniques should be left to the contractor, the 
modular approach to design can be specified in the contract 
as a mandatory equipment specification [Ref. 47]. 

The following points emphasize the need for command 
and control software to be designed for flexibility; 



1. Algorithms and data may need frequent revision 

due to the rapidly changing capabilities and nature of 
weapons systems and threats. Modular software, with its 

separation of "areas of change," will greatly reduce 
reprograming effort and cost and will lessen the risk of 
negatively affecting other portions of the software. 



2. User needs vary across users and 
over time. Some users prefer graphic di 
tabulated data. Some users will need 
instructions to operate the systems. Some 
expert users with experience and would become 
there were no means to bypass the more 
instructions for faster response [Ref. 48; pp. 



individually 
splays over 
more "help" 
will become 
frustrated if 
basic help 
16-17] . 



3. The decision-making processes for peacetime 
operations are distinctly different from those which are 
necessary for combat operations [Ref. 49; p. 93, Ref. 50; 
p. 15]. The DSS should support both of these decision- 
making processes and provide for a smooth transition from 
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one to the other. This means that while the system should 
provide different models, data and response times, it 
should not require any major changes in operation. 

4. The system will require changes as more is 
learned about command and control decision-making in 
general, and as the user provides feedback as to how the 
system could better meet his needs. Current knowledge of 
command and control decision-making is incomplete, and as 
weapons and tactics undergo constant changes, the study of 
such decision-making will be an ongoing effort [Ref. 22: p. 
34 , Ref. 8 : p. 96 ] . 

5. A modular design will reduce software maintenance 
efforts, which typically account for an estimated 67% of 
total effort expended on large-scale software systems [Ref. 
51: p. 204]. Maintenance involves correcting newly- 
discovered errors, performing planned updates and making 
adjustments for change in local conditions (such as changes 
in the hardware). Approximately 70% of the total cost of 
software systems over the life cycle occurs during this 
maintenance stage [Ref. 51: p. 204]. This figure could 
increase if the current upward trend in the cost of 
programming continues [Ref. 46: p. 136]. Simplified 
software maintenance is also particularly important for 
tactical systems due to the difficulty in providing skilled 
personnel to perform the maintenance and due to the impact 
of downtime on mission performance. 

6. A modular software design will permit separation 
of the communications processing subsystem and thus allow 
for flexibility in sources of data input [Ref. 52: p. 96]. 
This is an important consideration since communications 
media are subject to both natural disturbances and, in 
conflict, intentional disruption. The communications 
subsystem should be readily and easily r eprogr amable for 
such changes and should have no affect on the rest of the 
system, save perhaps a short time delay. 

7. If the database is limited by storage capacity, 
it may be desirable to provide off-line disk storage for 
different communications subprocessing programs, models, 
and data files. 



2 . Reliability 

A command and 
decision-making aid 



control DSS will no 
in peacetime. The 



doubt be a great 
commander will 
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appreciate a system which helps him filter and make effective 
use of all the data available to him. He will also grow 
accustomed to have such aid. The DSS would be 
counterproductive, however, if it ceases to function during a 
combat situation when he may most need it. It is therefore 
necessary to take every precaution to "harden” the system and 
to ensure the integrity and availability of its supporting 
data, models and hardware. The following discussions of 
hardware, communications and data model reliability will 
point out some of the potential problems which, if considered 
during the early development stages, can be countered with 
appropriate hardware and software techniques, 
a. Hardware Reliability 

Defense system requirements are vastly different 
from those of the commercial sectors. Command and control 
systems, in particular, require very reliable and rapid 
processing of real time data streams [Ref. 53: p. 358]. 

Furthermore, defense systems, especially tactical systems, 
are constrained by weight, power, and size limitations and 
are subjected to far more extreme environmental hazards such 
as high temperatures, radiation and vibration [Ref. 54: p. 
346] . 

The introduction of new hardware to support a 
command and control DSS provides an opportunity to improve 
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reliability through the use of 'Very Large Scale Integration' 
or 'Very High Scale Integrated Circuitry' (VHSIC). 



(1) VHSIC Technology . Commercial semi-conductor 
designs cannot meet the speed, density and reliability 
requirements of a command and control system [Ref. 55: p. 
340]. The VHSIC program was initiated in 1980 by the 
Department of Defense to overcome these technological 
barriers with the more capable chip. The new chips will 
provide more processing capability and higher throughput 
capacity. The reduction in vulnerable interconnections among 
chips which results, serves to increase reliability. The 
reduction in feature size of integrated circuits on these 
chips also allows for built-in testing techniques which can 
greatly simplify maintenance-- a distinct advantage in the 
tactical field [Ref. 56: p. 344]. 

(2) BMP Shielding . Solid state circuitry is 
very vulnerable to electromagnetic pulsing. Most new command 
and control systems programs have set aside funds for 
protective Faraday shielding at the "box” level. The larger 
the "box," the more expensive the shielding. VHSIC will 
greatly reduce the sizes of these components, or boxes, and 
thus provide savings in shielding costs [Ref. 57: p. 240, 
Ref. 5 : p. 27 ] . 

(3) Hardware Maintenance . Although the reli- 
ability of individual electronic components in military 
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systems has steadily improved over the years, the complexity 
of these systems has grown even more rapidly as a result of 
escalating performance demands. The amount and complexity of 
unscheduled maintenance is unacceptable and degrades mission 
performance [Ref. 58: p. 11, Ref. 59: p. 15]. VHSIC 

technology promises to greatly improve performance and 
reliability as well as the extra advantages of reduced 
"payload : " 

"...VHSIC technology could be used to reduce size, weight, 
power, failure rate, and unit cost, each by factors ranging 
from 20 to 200; the processing throughput could be 
increased by a factor of about 150" [Ref. 56: p. 343]. 

b. Data Communications Reliability 

(1) The Problem . Much of the data needed for a 
command and control DSS will be provided by real-time 
transmission over communica t ions media. As mentioned 
earlier, the DSS should not be affected by the need to switch 
to an alternate path or medium in the case of signal loss on 
the original path. It is also necessary to plan for the 
inability to reestablish communications, or the complete loss 
for an extended period of time of critical data sources. 

Signal degradation and path failure occur 
even in peace time due to equipment failure and inclement 
weather. The probability of losing communications circuits 
increases greatly when hostile forces deliberately attempt to 
jam, interfere or otherwise sabotage communications 
capabilities and facilities. Threats range from the 
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destruction of fixed communications stations and satellite 
earth terminals to laser attacks on the satellites 
themselves. The Soviets are developing laser-capable 
spacecraft which will threaten our communications satellites, 
and already they have the capability to blind our low-orbit 
(100 miles) satellites with their land-based laser devices 
[Ref. 60; pp. 16-19]. The threat to our satellite 
communications capabilities is an especially serious threat 
to the Navy as its tactical command and control is heavily 
reliant upon satellite links [Ref. 61; p. 49]. 

A NATO official describes the vulnerability 

of the data communications which support the NATO Air Command 

and Control System (ACCS) [Ref. 62; p. 16] ; 

"We see as a critical and vulnerable element of the ACCS 
the s u s c ep t a b i 1 i t y to jamming of its tactical 
communications links, with the probability that the flow of 
essential weapon control data would disrupted and the 
decision making process would be seriously inhibited at all 
levels. " 

The October issue of Defense '82 describes 
the vulnerability of "the major part, if not all, of our 
existing C3 capability” to a coordinated Soviet attack with 
air and sea-launched cruise missiles and long-range bombers 
[Ref. 63; p. 8]. Nuclear weapons pose an even greater threat 
in that Electromagnetic Pulses (EMP) can be carried for long 
distances in unpredictable directions by the atmospheric 
pressures. EMP is known to have the effect of "freezing" 
solid state circuitry, at least temporarily. A small two 
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megaton burst can damage an unprotected satellite up to 
22,500 miles away [Ref. 64: p. 27]. 

(2) Solutions . Lt. General William J. Hilsman, 
Director, Defense Communications Agency, expressed his 
concerns in a recent interview that the military 
communications system is too heavily reliant on fixed 
communications stations. Both he and the NATO ACCS officials 
support the theory that modern day warfare would be better 
supported by distributed data communications which do not 
rely on the continued operation of any one node. Already 
some C3 systems , such as the Joint Tactical Information 
Distribution System, are being developed to facilitate 
secure, flexible and jam-resistant data and voice transfer in 
real time among the dispersed and mobile elements of the 
military services [Ref. 65: pp. 15-17]. The concept of data 
distribution has not been easily accepted. It may be many 
years before the communications system architecture can be 
changed for less reliance on fixed stations, due to 
bureaucratic and organizational inertia and the general 
difficulty in getting command and control systems approved 
and funded through Congress [Ref. 58: pp. 11, 14]. 

The use of high frequency (HF) communications 
links will also add appreciably to the probability of 
successful communications. The reliability in peacetime 
operations of satellite links and the memories of once 
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unreliable HF path quality have resulted in the neglect of 
the HF frequency band. The new "chirp-sounder" equipment, 
currently being fielded by the Defense Communications Agency, 
has increased HF path reliability to 90% [Ref. 58: p. 12]. 
Chirp sounders automatically sample the spectrum for tuning 
into good frequencies. Also, the HF spectrum has a unique 
capability to propagate beyond line-of-sight using reasonable 
size antennas and relatively modest output power. 

Command and control DSS should be designed 
to take advantages of the capabilities of the HF frequency 
band as either a primary system or as backup to a satellite 
or other relay system. Jamming resistance can be provided by 
the use of frequency-hopping techniques and coded burst 
communication [Ref. 66: pp. 380-388]. 

Communications reliability can be also be 
improved by the use of redundant transmissions or dedicated 
back-up circuits. An analysis of information needs and 
available communications paths should identify the most 
survivable paths and backups for the high priority data 
needs. The DSS can then be designed to accommodate these 
communications media and to allow for flexibility to make 
necessary changes. The data analysis may also indicate a 
need to develop contingency plans for cases when 
communications cannot be reestablished for particular 
circuits. The loss of data may mean the inability to use 
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certain models available in the DSS. The commander should be 
aware of the affects of data communications loss on DSS 
operation and of possible alternate methods of receiving data 
(over voice circuits) for possible manual insertion. 

The point here is planning. The Soviets 
have invested heavily in Electronic Counter Measures, or what 
they call "Radio Electronic Combat" [Ref. 67: p. 10]. Until 
our C3 systems are fully survivable, it would be dangerous to 
allow commanders to become accustomed to or dependent on a 
decision-making system whose operation is dependent on the 
availability of vulnerable, limited data sources, without 
providing contingency plans. 

c. Model Reliability 

Models are what distinguishes a DSS from other 
information management systems. A command and control DSS 
will employ models to integrate data from a variety of 
sources, including real-time sensor sources, for the purpose 
of situation analysis. Models may also be provided within 
the DSS for performing combat simulations for planning 
purposes. 

Thus models used in a command and control DSS can 
range from the straight-forward algorithms used in 
calculating distance-to-target to the more complex, multiple 
variable, multiple algorithm models of threat evaluation. A 
Comptroller General Report to the Congress [Ref. 38] 
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distinguishes models as those which solve "rigorously 
quantifiable" problems and those which solve "squishy 
problems. " 

While all models are subject to design errors, it 
is the "squishy" problem-solving models which deserve 
particular attention by those who intend to have them 
incorporated into a command and control DSS. Once these 
models have been approved for the system, the intended users 
should also be made aware of both the capabilities and 
limitations of each model. Where possible it is even 
advisable to provide for user participation in the design of 
models. User understanding is important both for building 
trust in the system and for avoiding gross misinterpretation 
of results [Ref. 68: p. 57]. 

(1) Assumptions in Models . Modelling is more an 
art than a science. It is impossible, in many cases, to 
quantify some of the variables which contribute greatly to 
the outcome of events, such as the effects of darkness or 
stress, the complex interactions of weapons systems, and the 
roles of C3 and counter-C3. In other cases, it is necessary 
to omit even some quantifiable variable inputs due to the 
inability to process all the inputs in the necessary time 
frame. The model-builder must determine which variables are 
the most critical and of those, which can be included 
included for realistic processing times. His or her 
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assumptions, then, are one of the weaknesses inherent in the 
modelling process [Ref. 68: p. 56]. 

(2) Data Verification . Another basic weakness 
is the inability to verify data. Many of the calculations 
performed by combat models depend on quantifiable performance 
ratios of various weapons systems. Some of these weapons 
have had very little testing under realistic conditions. 
Nuclear weapons have undergone virtually no realistic 
testing. Even where data is available, it is subject to 
frequent change and rapidly outdated by weapons system 
technology. Sources for weapons data have sometimes been 
historical, often from unlocatable or inaccessible classified 
documents. Some figures are sheer estimates on the part of 
analysts. Currently there exists no single complete source 
of weapons data; the Command and Control Technical Center in 
the Pentagon has just recently begun to establish such a 
data bank. The lack of standard data has resulted in models 
which vary widely throughout the Department of Defense [Ref. 
69: pp. 73-78].. 

(3) Aggregated Models . Aggregated models are 
perhaps the "shakiest” of all models. They lump together 
similar types of weapons into a composite index which is then 
used to represent the combat power of a military force. Both 
the model and the input data for such aggregation involve 
critical assumptions about tactics, rates of fire and 
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distribution of that fire [Ref. 69: p. 56]. Use of such 

models should be for general planning and comparison purposes 

only. 

(4) Model Interpretation . If the builders of 
models could explain and document their assumptions to the 

end users, the current problem with interpretation might be 
somewhat alleviated. As it is, modellers have limited and 
infrequent contact with users or their organizations [Ref. 
69: p. 31] and documentation is as much a neglected item as 
it has been with most other Department of Defense software 
systems. 

(5) Com bining M odels . In defining information 
needs, it sometimes seems desirable to utilize outputs of one 
model as inputs to another [Ref. 69: p. 79]. It can be done, 
but experts warn that the programming effort will be 
horrendous [Ref. 70: p. 99, Ref. 71; p. 340]. Furthermore, 
errors in the first model can be so compounded by subsequent 
models as to invalidate the results [Ref. 68: p. 57]. 

(6) M odel Validation . A last warning, from a 

NATO operations analyst who creates combat models for a 

living, should emphasize the uncertainty inherent in the 

processes of modelling [Ref. 68: p. 55]: 

..in spite of the intellectual resources devoted on both 
sides of the Atlantic to modelling techniques, there is no 
agreed, coherent theory or set of criteria by which one can 
asses the suitability of any given model. 
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The point in this section on Model 

Reliability is not to discount the advantages or deny the 

need for the use of models, but instead, to develop a sense 

of caution in order that command and control DSS designers 

will demand documentation of assumptions in models and of 

data sources for models which will eventually support a 

decision maker's judgement, for [Ref. 69: p. 73] : 

.. when that judgement is 'extended' by a model -- a model 
that uses unverified assumptions that go beyond science and 
objective fact — how can the decision maker be sure that 
the model is in fact, serving as an extension of his/her 
own judgement... 

The next chapter on implementation presents 
the concept of a command and control system test bed. The 
test bed simulates the command and control environment and 
could be used as one check for validity of models. The real 
test will be actual combat use. Careful design and 
documentation will reduce the risk of costly error in actual 
use. 
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IV. COMMAND AND CONTROL DSS IMPLEMENTATION 



The evolutionary or prototype approach to implementation 
of a DSS is especially applicable to systems designed for 
command and control purposes: 

...every design problem begins with an effort to achieve 
fitness between two entities: the form in question and its 
context. The form is the solution to the problem; the 
context defines the problem. In other words, when we speak 
of design, the real object of discussion is not the form 
alone but the ensemble comprising the form and its 
context. Good fit is a desired property of this ensemble 
into form and context [Ref. 72: p. 33]. 

Fitting a DSS into the very complex context of command 
and control will require the flexibility of an evolutionary 
development approach. While government regulations and the 
military personnel turnover problem will complicate the 
implementation process, the results of a prototyping approach 
will better meet commanders' decision-making needs in the 
rapidly changing command and control setting. 



A. THE TRADITIONAL APPROACH TO IMPLEMENTATION 

The traditional approach to systems acquisition and 
implementation, still used for most command and control 
systems, follows a sequential approach from requirements 
definition, to advanced development, to fielding and support. 
Even when this sequence of events is iterated, the ultimate 
goal is the "freezing of the specs" in the requirements 
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definition phase. While this traditional process seems 
reasonable for weapons/platform acquisition, it is not 
advisable in unstructured settings [Ref. 73: pp. 1-8] as it 
intimidates the decision-makers, forces premature closing on 
problem-solving approaches, and inhibits the important 
learning and search processes that are essential for managers 
to undertake in addressing less strctured tasks. 

In general, DSS will experience a very short 
periodicity — or serviceabili ty--before requiring hardware, 
or more likely, software changes for restructuring, updating 
or expansion [Ref. 73; p. 5]. The following characteristics 
apply to command and control systems and should serve to 
explain their short periodicity [Ref. 74; pp. 19-20]; 

- Only a few of a kind are procured. 

- The systems are embedded in larger systems. 

- The measures of success are difficult to define. 

- Continuity of operations is essential. 

- The systems embody changing tactics and procedures. 

- The systems are software-dominated. 

A seventh characteristic which affects command and 

control systems periodicity is the unpredictability of 
funding [Ref. 58; p. 14]. Planned capabilities may have to be 
dropped when funds are cut in the eleventh hour. 

Thus a command and control DSS will be a unique set of 
software, custom tailored but flexible enought to meet the 
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specific decision-making styles and information requirements 
of a commander who operates in an unpredictable and rapidly 
changing environment. It would be very difficult to 
determine at once all the objectives of a given system or how 
the users will respond to particular configurations and 
capabilities. 

B. PROTOTYPING 

The prototype approach accommodates these uncertainties 
by phased implementation of versions, where the first version 
is a "breadboard" or minimum requirements system. The 
determination of the minimum requirements will require 
considerable time and effort up front [Ref. 74: p. 25]. 

Subsequent versions, providing funding is available, can add 
new capabilities, make modifications, or incorporate 
advantages of new hardware or spftware technologies, all 
based on user feedback from in-context testing. The concept 
of modular hardware and software design is highly compatible 
with the prototyping approach to implementation. Together, 
these techniques can produce a system which is designed from 
the start to accommodate growth and change and to accept 
"graceful insertion" of new technologies [Ref. 75: p. 39]. 

C. BENEFITS OF PROTOTYPING 

Some of the benefits of prototyping are, briefly [Ref. 
76: p. 65] : 
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1. Reduction of Total Cost 



Over one-half of the total software in command and 
control systems tends to be unique, costly, one-time 
development efforts. The modular approach to implementation, 
with its built-in expectation of change, reduces overall 
development and maintenance costs [Ref. 77: p. 50]. 

2 . Reduction of Initial Risk 

Instead of dedicating large dollar amounts and human 
resources to a long-term, "one-shot" program which defies 
evaluation until completion, prototyping allows minimum 
initial investments and constant evaluation. Success at each 
stage could make the next stage easier to justify and fund. 
Errors are more easier and less costly to track to sources, 
and corrections of errors are less likely to cause unexpected 
changes elsewhere in the system. 

3 . Slower Obsolescence 

Changes in tactics, weapons or other decision-making 
criteria will not render the system obsolescent as it can be 
more readily adjusted to accommodate those changes. 

4 . Higher Operational Readiness 

Prototyping can provide for the early fielding of 
minimum capabilities rather than the long delay in waiting 
for an entire system to be developed. 
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D. RESOURCE REQUIREMENTS FOR PROTOTYPING 

The prototyping approach requires the availability and 
skilled use of advanced software techniques in order to 
facilitate the many changes to versions. The following 
resources will provide programming and design advantages 
which can speed the development effort and prevent the 
problems of constantly "reinventing the wheel" with each 
version [Ref. 72: p. 34]: 

1. DBMS 

A database management system (DBMS) will provide for 
rapid and relatively-easy creation, revision, and extension 
of data access methods, storage structures and security 
measures. Ideally, the DBMS will have extensive reporting 
facilities for design management purposes. 

2 . Generalized Input/Output Software 

Output formats and displays can be more rapidly 
designed with the use of report generators, report writers 
and query languages. Generalized input software automates 
the editing, validation and error correction procedures which 
would otherwise complicate and lengthen the process of 
changing the database. 

3 . Programming Languages 

While most command and control algorithms may require 
the efficiency of assembly language, high level languages can 
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be used where efficiency is not paramount, for simplified 
coding, testing and documentation. 

4 . Modelling 

The need for models has already been discussed. The 
use of a model base management system for the integration of 
models into a "model bank" is advisable for rapid 
construction and use of models [Ref. 70; pp. 98-110]. 

5 . Time 

To the above resources as offered by Naumann and 
Jenkins, it seems necessary to add the element of time as a 
resource. Prototyping depends on user evaluation in context. 
Thus the user must be able to dedicate sufficient time, away 
from his other duties, to experiment with and evaluate each 
version. For some command and control systems it may prove 
difficult to test versions on the very platforms in which 
they will operate. Tight operating schedules may indicate 
the need to make use of a command and control test bed to 
simulate the intended operational environment [Ref. 78: pp. 
103-106] . 

E. DISADVANTAGES OF PROTOTYPING 

All methods have drawbacks. The following disadvantages 
apply to prototyping for most DSS [Ref. 79: p. 22]: 

- Large amount of user time required 

- Requires highly talented system designer 

- Possible reprogramming needed for efficiency 
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- Lack of standards and documentation can complicate 

maintenance 

- Highly susceptible to user/implementer turnover 

- Continuous change can be frustrating 

- Unweildy with more than 2 or 3 users 

The user /des igner turnover problem is one that the 
military, with its policy of rotation, will have to live 
with. In at least one DSS case, it has resulted in the 
complete failure of the system [Ref. 80: pp. 542-455]. The 
other problems mentioned by Alter, can be approached with 
good planning and use of resources and the establishment of 
good user-designer relations. 

A problem not mentioned by Alter, and probably unique to 
federal systems acquisition, is the difficulty in getting 
away from the traditional systems development process. A new 
Department of Defense Instruction 5000.2 for evolutionary 
acquisition has not been applied consistently "partly because 
the concept of evolutionary acquisition is not well 
understood, and partly because of resistance to the special 
management procedures and changes.. which are required" [Ref. 
81: p. 9]. 

F. SUMMARY 

The rapidly changing environment which distinguishes 
command and control calls for an acquisition and 
implementation strategy which allows for greater flexibility 



45 



and user involvement than is possible with the traditional 
phased development process. Personnel turnover and rigid 
governmental acquisition regulations may complicate the 
process, but the prototype approach to implementation seems 
the most promising for the accommodation of change, growth 
and new technology insertion, as well as budget limitations, 
of command and control systems. 
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V. SUMMARY AND CONCLUSIONS 



Command and control DSS have the potential to fulfill the 
information requirements of individual commanders while also 
filling the gap of distributed decision-making between 
service echelons and across service systems. Already there 
is a strong movement underway to apply the concept of DSS to 
command and control purposes. The command and control DSS 
which are currently under development are breaking new 
ground. There is as yet, no one source of guidance for the 
designers or project managers of these systems. Current 
texts have been written for strictly commercial purposes 
such as banking and finance. These texts provide a wealth of 
information about the design techniques used in creating DSS, 
but do not address issues which are critical for the design 
of military DSS. 

Military decision-making involves several echelons of 
command authority, real-time communications-dependent data, 
highly unpredictable events and results which can affect 
national defense. For these reasons, careful consideration 
must be given in the early development phases, of the 
following issues: 

- The affects of the DSS on the organization's decision- 
making processes 

- Optimal use of available DSS capabilities 
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- Interoperability with other systems as necessary 

- Identification of tactics and strategies 

- Legal issues of command resposibility in use of DSS 

- Current and expected requirements for reliability 

- Support for both peacetime and combat decision-making 

- Decision-making styles of users 

- Likely "areas of change" for separation into modules 

- Availability/ease of software and hardware maintenance 

- Reliability of data communications sources 

- Protection against EMP 

- Possible advantages of VHSIC 

- Reliability of supporting models 

- User understanding and acceptance of models 

- Advantages of evolutionary approach to implementation 

- User involvement in design and implementation 

These are all considerations which will involve 
approaches and problems unique for command and control 
systems. The answers will not be found in current literature 
on DSS. Some suggestions have been made in the preceeding 
chapters, but specific solutions to problems will, of course, 
depend on the particular context and applications of each 
system. It is hoped that this thesis will stimulate further 
research and interest in the identification of methods and 
techniques which will result in more capable, reliable 
command and control Decision Support Systems. 
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APPENDIX A 



A SUMMARY OF CURRENT LITERATURE ON DSS 



The concept of a DSS has evolved since Michael S. Scott 
Morton's description in the early 1970's of a management 
decision system. Today a standard definition of a DSS is; 

...an interactive computer-based system which helps 

decision-makers utilize data and models to solve 

unstructured problems [Ref. 82: p. 40]. 

The following characteristics of a DSS were determined by 
300 users, developers, researchers and vendors at the First 
International Conference on Decision Support Systems in June 
1981 [Ref. 82 ; p. 6] : 

- Aimed at the less we 11- s t r uc t u r ed , underspecified 
problems typically faced by upper-level managers 

- Combine use of models or analytic techniques with 
traditional data access and retrieval functions 

- User initiated and controlled 

- User-friendly with rapid response 

- Tailored to individual decision-maker's style and 
information needs 

- Flexible and adaptable to accommodate changes in 
environment and decision-making approach of user 

Some additional characteristics of a DSS as presented by 

authors of important texts on the subject; 

- Focus on improving effectiveness of manager's decision 
process [Ref. 21: p. 2 ] 
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- Provides managers with access to both internal and 
external data sources [Ref. 82: pp. 31-32] 

- Usually requires separate, or extracted, data base to 
accommodate user's personal and unofficial data and 
information 

A. DSS VS. EDP AND MIS 

Before developing further these DSS concepts, the 
following descriptions of Electronic Data Processing (EDP) 
and Management Information Systems (MIS) may help to clear 
some of the difficulty and controversy with the terms DSS, 
MIS and EDP. 

EDP was the earliest form of computer support to 
organizations. It involved automation of large-scale, 
batch, operations such as payroll, invoicing, inventory and 
record-keeping. The emphasis was on the automation of 
routine data or transaction processing. Basic EDP 
characteristics include [Ref. 82; p. 6] ; 

- Focus on data, storage, processing, and flows at the 
operational level 

- Efficient transaction processing 

- Scheduled and optimized computer runs 

- Integrated files for related jobs 

- Summary reports for management. 

With the more sophisticated, third-generation computers 
and their economies of scale, higher-level languages, 
operating systems, remote terminal and query capabilities, 
organizations began in the latter 'sixties to develop more 
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integrated sets of specific data bases. These data bases 
tended to be centrally located and organized by functional 
applications. Such MIS systems are the most common type of 
computer support in organizations today. The introduction in 
the latter 'seventies of complex database management systems 
(DBMS) has permitted the sharing among functional 
applications of pertinent organizational data and 
information. Report-generation capabilities have made 
possible the request and receipt of summaries by managers, 
often from their remote terminals. 

The name 'MIS' has been somewhat misleading. Most 
experts today contend that the rigid reports produced by MIS 
have had little significant impact on management decision- 
making processes [Ref. 83: p. 3]. Some critics have gone so 
far as to imply that "MIS is a mirage" which has merely 
created more data for the already over-burdened manager [Ref. 
84: pp. 123-132] . 

In any case, the following characteristics are usually 
associated with MIS [Ref. 21: pp. 1-2, Ref. 82: pp. 7, 31] : 

- Information-focused for middle managers 

- Impacts structured tasks, where standard operating 
procedures, decision rules, and information flows can be 
reliably predefined 

- Integration of EDP jobs by business function (personnel, 
marketing, etc.) 

- Inquiry and report-generation capabilities 
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- Emphasis on efficiency (costs, turn-around time, 
personnel reductions) 

- Indirect support for managers decision-making, in the 
form of reports and access to data 

- Database restricted to internally-generated aggregate or 
historical data. 

MIS continues to hold an important position in most 
organizations as is evidenced by the growing number of 
journals and articles devoted to the value of information. 
Information Resource Managers, database management systems, 
and other such concepts related to the development, 
maintenance and management of organizational information 
resources. Two recent and important factors, however, are 
beginning to stimulate interest in the more decentralized and 
personal DSS application of computers. One of these factors 
has been the increasing familiarity with and acceptance by 
managers of the capabilities of the computer. The second 
factor is the need to exploit the new hardware and software 
technology to help managers make better decisions in an 
environment which has suddenly become characterized by 
inflation, uncertainty, economic swings and governmental 
regulation [Ref. 21: p. 4]. The DSS emphasis on effectiveness 
is more appropriate for dealing with change than is the 
efficiency provided by MIS [Ref. 85: pp. 19-34]. 
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B. EFFECTIVENESS VS. EFFICIENCY 

While the ultimate goal of any manager or organization 
would be to achieve both effectiveness and efficiency, the 
two criteria of performance must be balanced and play 
different roles depending on the maturity and environment of 
the various organizational functions. Efficiency implies 
maximum output for minimum input. It is essentially 
programmatic in mature organizations operating in stable 
environments. Effectiveness, on the other hand, involves 
more judgement in identifying what must be done and how it 
must be done. It requires adaptation and learning, at the 
risk of redundancy and false starts. For example, while 
research and development can be thought of as a risky and 
inefficient investment of resources, it's purpose is usually 
to provide for future effectiveness [Ref. 21; p. 7]. 

C. STRUCTURED VS. UNSTRUCTURED 

The above destinction between effectiveness and 
efficiency in decision-making is central to the concept of 
DSS and their application to unstructured or semi-structured 
problems faced by managers. Most texts on the subject of 
DSS's employ Herbert C. Simon's paradigm of problem-solving 
processes to explain the continuum of structured through 
unstructured problems. Basically, he has stated that the 
process of problem-solving involves three discernable, but 
iterative steps [Ref. 86; p. 6]: 
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- The intelligence phase--sear ching the environment for 
conditions calling for decision. Gathering data 



- The design phase--inventing, developing, and analyzing 
possible courses of action 

- The choice phase — selecting a particular course of action 
from those available. 

Problems, or the process of problem-solving, then can 
range from the structured to the unstructured, depending on 
how easily identified are the information needs and processes 
involved in each of these three problem-solving steps. 
Structured, or as Simon calls them, programmed decisions 
are ; 



...repetitive and routine, to the extent that a definite 
procedure has been worked out for handling them so that 
they don't have to be treated de novo each time they occur 
[Ref. 86 : p. 7 ] . 

That is, each phase can be readily described and thus could 
be programmed for computer processing. Transactions for 
customers can thus be handled completely automatically at 
bank automated cash tellers. 



Unstructured, or non-programmed decisions, on the other 

hand, are novel and consequential. Simon continues: 

There is no cut & dried method for handling the problem 
because it hasn't arisen before, or because its precise 
nature and structure are elusive or complex, or because it 
is so important that it deserves a cu s tom- ta i lor ed 
treatment. ...the system has no specific procedures to 
deal with situations like the one at hand, but must fall 
back on whatever general capacity it has for intelligent, 
adaptive, problem-oriented action. 

Most DSS experts agree that such problems remain unsupported 

by computers today and are left strictly to the manager's 
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judgement and experience. None of the steps in Simon's 
decision-making or problem-solving paradigm can be 
programmed. In the intelligence phase, we are unable to 
define the conditions that allow us to even recognize the 
problem. We are likewise unable, in the design phase, to 
specify how to create methodologies to solve the problem. An 
example of such a problem would be the forecasting of women's 
taste in shoes. No clear criteria can be identified for 
selecting a best solution in the choice phase. Thus, the 
entire problem is unstructured [Ref. 21: p. 95]. 

Most problems, however, fall somewhere between these two 
extremes and are called "semi-structured" problems. One or 
more of the phases of intelligence, design, and choice can be 
defined. This is where DSS can be the most effective. 
Semistructured problems or tasks require the judgement of the 
manager or decision-maker for those unspecif iable phases, but 
can be supported by models or data which reflect the known 
criteria for the other phases. Often, with experience and 
knowledge gained over time, such problems can become 
sufficiently structured to permit total automation. Until 
then, however, the man-machine interaction provided in a DSS 
can provide more effective solutions for semi-structured 
problems. 
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D. INFORMATION NEEDS DIFFER 

Three categories of managerial activity have been 
identified by Anthony [Ref. 87: pp. 24-27] as distinguishable 
in that, while each faces semi-structured problems, their 
information needs differ in scope, detail and currency. 
Strat e gi c planners need aggregate data for long-range 
planning. Management control personnel need some degree of 
detail and operate in shor ter-range planning to translate 
strategic plans into resource requirements. Operational 
control personnel use detailed and current data for direction 
of actual production. 

Anthony's framework has implications for the design and 
development of DSS's. First, it is apparent that all levels 
of managerial activity are involved in semi-structured 
problem solving. Thus DSS application in the organization is 
not restricted to top management. Secondly, given the 
differing information needs and characteristics associated 
with each level, it follows that DSS's must be highly 
tailored to the specific use or developed with sufficient 
capabilities and flexibility so as to permit rapid transition 
from one type of task or problem to the next. It is also 
evident that the supporting data base for DSS's in 
operational control would differ radically from that which 
would support DSS's in the strategic planning area. The same 
can be said for the types of models incorporated in DSS's 
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which support these different managerial activities. 
Furthermore, the design, development and implementation of 
DSS's among different managerial activity levels would 
necessitate the involvement of different specialists from the 
systems group in the organization. 

E. COMPONENTS OF A DSS 

To realize the potential of a DSS in any of the organi- 
zational contexts described above, a set of hardware and 
software components must be designed and assembled. While 
the particular design will depend on the specific application 
of the DSS, some generalizations can be made about the basic 
components. First, and most importantly, a DSS involves the 
human decision-maker. This decision-maker, usually a manager, 
operates in a unique environment and is responsible for a 
given number of tasks. Figure A-1 illustrates the relation- 
ship between the decision-maker, the task, the environment 
and the collection of components which make up a DSS. 



DSS 

^ ^ 

decision-maker 
Figure A-1. Man-Machine Environment 
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environment 
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The components which make up the DSS include a data base, 
a model base, and a dialog language which interfaces the 
decision-maker with the system. Each of these components 
requires an associated management system to permit 
manipulation and access by the user. Figure A-2 depicts the 
logical relationship of these components and their respective 
management systems [Ref. 82: p. 29]. 






dialog 



user 

Figure A-2. DSS Components 
1. The Dialog Subsystem 

The dialog subsystem of a DSS is the DSS in the eyes 
of the user. All of the capabilities of the DSS must be 
articulated and implemented through the dialog. This dialog 
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subsystem can be further broken down into three parts [Ref. 
81 : 2p. 30 ] . 

a. The Action Language 

What the user can do in communicating with the 
system. May include such options as the availability of a 
regular keyboard, function keys, touch panels, joy stick, 
voice commands, etc. 

b. The Display or Presentation Languages 

What the user sees. The display language includes 
opinions such as a character or line printer, a display 
screen, graphics, color, plotters, or audio output. 

c. The Knowledge Base 

What the user must know to use the system 
effectively. May consist of a manual of available commands 
and their descriptions. May be displayed on the screen or 
available upon request with a "help" command. 

The richness and flexibility of the dialog 
interface will depend on the strength and variety of these 
capabilities. The success of the entire DSS depends in large 
part on how user-friendly the dialog subsystem appears to the 
user. Managers seldom wish to learn complex languages or to 
memorize illogically-designated commands for functions. The 
more logical the commands and the more the dialog resembles 
natural language as employed in the context of the task at 
hand, the more likely the system is to be used and 
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appreciated by managers. The following capabilities of a 
dialog subsystem further enhance the chances of success of 
the DSS [Ref. 82: p. 31]: 

- The ability to handle a variety of dialog styles, and to 
shift among them at the user’s choice 

- The ability to accommodate user actions with a variety of 
input devices 

- The ability to present data with a variety of formats and 
output devices 

- The ability to provide flexible support for the user's 
knowledge base. 

Dialogs can take the form of question and answer 
routines, report format blanks, menu selections, or command 
languages. Most DSS will incorporate some combination of 
these for wider application and increased flexibility. They 
usually include other conventions to provide error messages, 
acknowledgements, verification requests, default values, and 
possibly override features for experienced users [Ref. 82: p. 
207] . 

The choice of a dialog form is an important 
decision in the design of a DSS for two reasons: (1) an 

inappropriate format will discourage use of the DSS and 
thereby reduce its effectiveness, and (2) the dialog 
component of a DSS often constitutes the largest percentage 
of the total code in a DSS, and thus the most expensive [Ref. 
82: p. 217]. 



60 



i 

1 



The design of the dialog component should begin 
with an analysis of the decision-making process and 
environment of the user. Such an analysis would identify the 
communications style of the user, the r esponse- t ime 
requirements, the desired outputs, and the required input 
parameters. The goal should be to provide effective 
representations or displays and understandable control 
mechanisms. In many cases, software packages can be 
purchased 'off the shelf to meet the needs of the user and 
reduce development costs. Some applications, on the other 
hand, are so unique as to require programming, either in- 
house or by a contractor. 

The effectiveness of a chosen dialog can be 
measured by number of errors, learning time, user perceptions 
and, although more difficultly, by effect on the decision- 
making process and its results, (i.e., number of alternatives 
analyzed) [Ref. 82: p. 207]. 

2. The Data Subsystem 

The data subsystem of a DSS is visible to the user 
only through the use of the dialog to access desired data. 
Recent advances and developments in database management 
provide a number of powerful functions, often in the form of 
"off the shelf" packages. However, the data base of a DSS 
differs from that of a MIS in two significant ways; it is 
dependent on external sources as well as internally-generated 
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data, and it must accommodate individual user's needs for 
storing and rapidly accessing both personal and corporate 
data. For these reasons, it is often necessary to create for 
the DSS a separate data base, part of which is extracted from 
the general corporate data base (or MIS) and part of which is 
drawn from external data sources. Figure A-3 illustrates the 
concept of the extracted data base [Ref. 82: p. 32]. 

source data 



internal 



finance 
marketing 
personnel 
manuf actur ing 



external 



i data extraction 

I 

/|\ 

'-Z 



dss data base 
system 




user 



Figure A-3. Extracted Data Base 
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Carlson and Sprague identify some desirable features 
of a DSS data base subsystem [Ref. 82; p. 32] ; 

- The ability to combine a variety of data sources through 
a data capture and extraction process 

- The ability to add and delete data sources quickly and 
easily 

- The ability to portray logical data structures in user 
terms so that the user understands what is available and 
can specify needed additions and deletions 

- The ability to handle personal and unofficial data so 
that the user can experiment with alternatives based on 
personal judgement 

- The ability to manage this wide variety of data with a 
full range of data management functions 

When the user of a DSS invokes the dialog to gain 
access to the data base, it is the Database Management System 
(DBMS) which actually translates the request and accesses the 
data base to create, maintain, update, or display data as 
instructed. In some DSS designs it may be possible to share 
the DBMS which serves the central corporate information 
system. Usually, however, it is wise to incorporate in the 
DSS a separate DBMS for faster response time and more 
flexible data retrieval functions. 

Conversely, it is seldom recommended that the DSS 
design should attempt to create an entirely separate data 
base of its own. Instead it should take advantage of the 
involved and time-consuming efforts already invested in the 
corporate data base. This can be accomplished by referencing 
the corporate data base whenever data is needed or by 
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periodically extracting needed elements into a smaller and 
separate DSS data base. Reliance on the corporate data base 
for internally-generated data needs results in decreased 
costs, more consistent and reliable information, simplified 
DSS design and development and fewer security problems [Ref. 
82; p. 223]. 

Data resident in the data base can be organized in a 
number of ways. Generally, a DBMS is designed specifically 
for the one particular organization of data within the data 
base. Thus, the selection of the DBMS for a DSS depends on 
the data model used in the corresponding data base, which, as 
described above, is probably already functioning within the 
organization. 

The various data models are described briefly below; 

- Record Model; Data is organized by records which are 
composed of related fields. Usually each record has one 
or more key fields which permit sorting of the data by 
attributes recorded in that field. For example, each 
customer's record identifies all loan accounts 
corresponding to that customer. 

- Relational Model: Data is organized in records and 

fields, where records are grouped by relation. For 
example, all car loan accounts are grouped separately 
from all signature loan accounts. 

- Hierarchical Model: Data is organized as in the 

relational model but the various groups are stratified, 
with upper-level groups having access to relational 
groups at lower levels. For example, the upper-level 
group of all loan accounts by number can access the 
lower-level groups of associated customers by loan 
account number. This model creates data redundancy and 
can be difficult to alter or update, but provides other 
offsetting benefits such as faster access and less need 
for the user to understand the data organization. 
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- Network Model; Much like the hierarchical model except 
that data redundancy is eliminated or reduced by the use 
of logical versus actual records. Pointers are used to 
direct search procedures to the actual location of 
desired records instead of duplicating them wherever they 
are related to a group. 

- Rule Model: Often called 'knowledge-based' systems, 

these models organize data and information in the form of 
rules or conditions. For example, when asked to compute 
a credit rating, the DBMS for a rule model would 
determine the necessary data input based on its rules for 
such a computation, would access or request input of such 
data, and would follow a predetermined set of "if - then" 
production rules to examine assets, liabilities, etc. in 
order to determine loan elligibility. This type of model 
is gaining increased recognition as it can support the 
speed and self-updating requirements of Artificial 
Intelligence [Ref. 88: p. 560]. 

Another criteria for selecting a DBMS for a DSS is 
the required number and variety of data operations and 
integrity constraints. Data operations include such 
capabilities as: 



dictionary 

creation 

deletion 

update 

query 



views 

protection 

sharing 

recovery 

file optimization 



Several other DBMS choice criteria are listed and 
briefly explained below. It is important to remember that 
the more capable the DBMS, the more overhead will be involved 
in processing time and in development costs. The need for 
these capabilities must be weighed against both the overall 
development costs and the differences in processing or 
response time to the user. 
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- Support for Memory: Workspaces for intermediate results; 

libraries for saving workspaces; links or indices; 
triggers to remind decision makers of needed data or 
operations 

- Data Reduction: Abstraction from large amounts of 

data through subsetting, combination, or aggregation 

- Detail Focus: To permit managers to focus on necessary 

level of detail 

- Multiple Source: Ability to access various internal and 

external data sources 

- Catalogue of Sources: To identify for the manager's 

intelligence-gathering phase of decision-making, all 
available sources of relevant information 

- Wide Time Frame: To permit analysis of both historical 

data and projections of current data into the future 

- Private Data Bases: At least part of the DSS data base 

should be accessible only by the user 

-Varying Degrees of Accuracy: At times the manager may 

need precision; other times he may prefer to 
"satisfice” and use estimates in order to save time on 
less critical decisions. Should provide indication of 
degree of accuracy of data supplied user 

- Random Access: Fast access to desired data. Serial 

access probably too slow and frustrating for managers 

- Transparency to the User: Users generally not skilled or 

interested in programming languages. User should be free 
of need to know details of data storage 

3 . The Model Subsystem 

While decision-making models have been developed for 
many years, managers seldom became adept or interested in 
their use and have relied instead on their own heuristic 
methods of problem-solving. The integration of appropriate 
models, data, and a method of communication and flexible 
manipulation among models and data as permitted by a DSS 



provides managers with the flexibility and and ease of 
manipulation which was not available with the independent 
models. Thus, managers provided with DSS's are much more 
likely to develop an appreciation for the "what-if” analysis 
capabilities of models or simulation [Ref. 82; p. 258]. 

The modeling component of a DSS is the primary tool 
for supporting the design and choice phases of decision- 
making. These phases include such activities as [Ref. 82; p. 
260] ; 

♦projection *deduction 

♦analysis ♦creation of alternatives 

♦comparison ♦optimization 

♦simulation 

In general, support for these activities depends on feedback 
and interaction between the decision-maker and the modeling 
component. The DSS should allow the examination of 
intermediate results, the accommodation of subjective 
judgement, and modification of input or model choice as the 
problem, or the user's perception of the problem, changes. 
Other key capabilities required of a DSS's modeling component 
include [Ref. 82; p. 33]; 

- The ability to create new models quickly and easily 

- The ability to access and integrate model building 
blocks" 

- The ability to catalogue and maintain a wide range of 
models to support all levels of users 

- The ability to interrelate these models with appropriate 
linkages through the data base 
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- The ability to manage the model base with management 
functions analogous to data base management (e.g., 
mechanisms for storing, cataloging, linking, and 
accessing models) 

Barbosa and Herko identify several other important 
requirements of a DSS modeling component [Ref. 89; pp. 1- 
12 ] ; 

a. Interface 

The user should be able to work in the problem- 
solving environment without unnecessary distractions. The 
user should not have to interrupt this process and 
laboriously supply some control parameters before continuing. 

The control parameters should be expressed in 
terms with which the user will be familiar. He or she should 
be able to think about only those parameters that have a 
direct bearing on the problem-solving process. 

b. Control 

The user should be given a spectrum of control. 
If possible, the system should support manual operation as 
well as fully automatic operation. This permits the user to 
select the level of algorithmic operation that seems most 
suitable. It also enables the user to learn more easily by 
allowing him or her to proceed as slowly as desired. 

The control mechanism should allow the user to 
introduce subjective information as demanded by the problem 
solution process. It should not require the user to specify 
all constraints a priori. This direct human control of the 
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solution process can make up for deficiencies in the 
algorithm and will often permit the system to contain a 
simpler algorithm, frequently resulting in smaller 
information burden on the user. 

c. Flexibility 

The algorithmic and manual operations should be 
interchangeable in the sense that the user can develop part 
of a solution via manual methods and then continue with the 
algorithm, or vice versa. This statement implies that the 
range of all operations can be cascaded in an arbitrary way. 
Both flexibility and control allow the user to construct a 
solution process that best suits the problem. This idea of 
interchangeability of operations is deceptively simple, but 
it has far-reaching implications. This is the manner by 
which flexibility and control are achieved. Thus a creative 
solution process can be composed of a sequence of 
subprocesses. 

d. Feedback 

The system should provide sufficient feedback so 
that the user is fully cognizant of the state of the solution 
generation process at all times. This feedback is essential 
for supporting human control of the process. 

The design process itself should make use of 
feedback. Valuable information can be derived from 
introduction of the initial system or prototype to the users. 



69 



Their feedback should be especially meaningful in the area of 
usability. 

The modeling component will be comprised of a 
model base, or library, and a software system to manage the 
models in the library. This management software is known as 
the Model Base Management System (MBMS). It also serves to 
interact with both the DBMS and the DGMS of the data base and 
dialog components, respectively. 

The model base will contain both canned and user- 
built, ad-hoc models designed to support a variety of tasks 
at any or all of the three levels of managerial activity. 
Smaller models may be used as building blocks for creating 
larger ones. 

The MBMS will handle the storage, retrieval, 
manipulation, creation and operation of the models in the 
model base. It will interact with the dialog component to 
permit the user to accomplish interactive modeling which 
permits interruption, sequence variation, and parameter 
changes. It will interact with the data component of the DSS 
to access input data, to update data based on results, to 
accept updates necessitated by changes in the data base, and 
to store intermediate results [Ref. 82; p. 263]. 
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F. SUMMARY 



DSS imply the integration and management of data, models 
and an interactive dialog to extend a user's judgement by 
permitting analyses of data. DSS are not replacements for, 
but rather, aids to the human decision-making processes. 
Each application will involve the tailoring of the user's 
data requirements to a specific decision-making context. 
Choices of database management design, dialog styles and 
supporting models are therefore highly context-dependent. 
The goals of applicability, flexibility and ease of use are 
common to all DSS. The degree to which these goals are 
realized in the design and integration of the basic 
components will largely determine the success or failure of 
the system. 
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